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This paper presents a method for performing large-scale design integration, taking a 
classical 2D drawing envelope and interface approach and applying it to modern three 
dimensional computer aided design (3D CAD) systems. Today, the paradigm often used 
when performing design integration with 3D models involves a digital mockup of an overall 
vehicle, in the form of a massive, fully detailed, CAD assembly; therefore, adding 
unnecessary burden and overhead to design and product data management processes. While 
fully detailed data may yield a broad depth of design detail, pertinent integration features 
are often obscured under the excessive amounts of information, making them difficult to 
discern. In contrast, the envelope and interface method results in a reduction in both the 
amount and complexity of information necessary for design integration while yielding 
significant savings in time and effort when applied to today’s complex design integration 
projects. This approach, combining classical and modern methods, proved advantageous 
during the complex design integration activities of the Ares I vehicle. Downstream processes, 
benefiting from this approach by reducing development and design cycle time, include: 
Creation of analysis models for the Aerodynamic discipline; Vehicle to ground interface 
development; Documentation development for the vehicle assembly. 
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I. Introduction 

M odem CAD systems have facilitated significant gains in the speed, accuracy, and efficiency of the 
structural/mechanical design process. These gains have reduced risk and contingencies associated with the 
design activities by allowing greater visualization and understanding of the design, faster, more accurate prediction 
of mass properties, and the parameterization of the design for operational, functional, or assembly optimization. 

While CAD technology has improved many aspects of the design process, the integration, utilization, and 
management of large CAD design datasets can be extremely cumbersome. These issues are commonplace in 
industry irrespective of whether working in a commercial or government environment and are often topics of 
discussion in design publications'. CAD datasets can become so large their integration at the vehicle level 
significantly increases the overall design cycle time. In other words, the CAD datasets are so large that extraction of 
the pertinent data required for integration takes longer than performing the design integration activity(s), e.g. 
reconciliation of the interfaces and creation of design integration products. These effects are exacerbated when 
integrating multiple datasets, sometimes modeled in different CAD software packages, as well as from multiple 
sources, such as those found in Launch Vehicle Systems. In order to perform the vehicle design integration activity, 
the methods we present in this paper incorporate the use of packages of extracted CAD data as an improvement 
upon the exchange, utilization, and integration of a large, comprehensive design dataset. The methods presented in 
this paper have been incorporated into NASA MSFC Handbook, MSFC-HDBK-3644 2 , which describes not only the 
use of envelopes and interfaces for vehicle integration but also provides support in the areas of vehicle alignment, 
and integrated control models. 

As an example of a critical part of the integration activity performed early in the design cycle, Aero analysis is 
often a lengthy process. Any methods used to shorten the pre-work for creation of these analysis models is 
advantageous. Commonly, the analysts must build their model from full detail CAD models or drawings, and the 
development time can be significant. A more efficient method is the creation and use of a single surface envelope 
representing the stage element or vehicle (devoid of all internal components); this is called an Outer Mold Line 
(OML) envelope. This envelope is widely used in Vehicle Design Integration. Usage of a single surface OML 
envelope results in the ability for rapid integration into the vehicle level assembly and provides disciplined control 
of the configuration, be it element or vehicle. The overall time to create an OML is marginally more than a detailed 
drawing representing the same information. It can be imported into most analysis tools either utilizing the CADs 
native format or through a neutral format such as STEP or IGES. Typically the stage (or element) design integration 
activity is responsible for creating its own single surface OML envelope and ensuring it accurately represents their 
comprehensive CAD dataset. 

Another area of improvement in large scale design integration is in interface development. Vehicle level 
interfaces are often controlled in a drawing, a document, or a combination of both. Typically, these interface 
definitions depend upon images derived from a massive, comprehensive set of design CAD files which contains, 
among other things, the definition of the interface. Rather than exchanging large assemblies (or entire element 
datasets), which often require extensive translation, verification, and downstream management, it is more efficient to 
share a subset of data that contains only that information that is necessary to define the interface. This interface 
information is collected together into a package containing a subset of the comprehensive design dataset, and 
additional dimensional data, notes, etc., associated with a specific interface. While this interface package is used 
(primarily) in the development of vehicle level interfaces, it can also be utilized in other vehicle integration activities 
such as the production of integrated assembly drawings. Besides interface development, the concept of packaging 
subsets of data can be applied to other areas of vehicle design integration in order to facilitate working within the 
constraints of large datasets. 


II. Envelopes 

The OML product is a 3-D CAD envelope model documenting the exterior surfaces of an end item shown in its 
nominal form and “as-designed” condition. It consists of an accurate set of joined, knitted surfaces forming a water- 
tight contiguous body representing the nominal “as-designed” hardware in the launch and/or flight configuration. 
The surface must be contiguous so that integration of lower level envelopes, such as elements or sub-elements can 
be combined to create a top level integrated envelope. This also assists with downstream surface simplification (for 
CFD grid generation), and the computation of volumes and areas. Typically an OML represents the exterior only 
definition of the vehicle body, but when in context of staged-flight or reentry analysis, cavity regions that become 
exposed should also be included. The OML, whether element or integrated vehicle, should be stand alone from any 
external references, i.e. no links to the geometry, parts, and assemblies it was generated from. The sheer size and 
complexity of the comprehensive datasets prevents efficient maintenance of geometric references, leading to a high 
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probability of failures during attempted updates. Once separated from these references, the data can be further 
processed using direct modeling methods. One drawback that must be managed in the process is that, since these 
associated references are not maintained, changes to drawings or comprehensive roll up OMLs are not readily 
updateable through normal methods. 

The concept of using envelopes in CAD is common place with most major CAD tools using features which 
create a “shrinkwrap”. These out of the box methods; however, were found to be insufficient when working with 
larger assemblies and performing integration activities. One example of the problems inherit with creating OML 
envelope models of large assemblies is the tendency of the software to omit small surfaces; resulting in a non- 
contiguous OML envelope (not water-tight), unsuitable for downstream applications such as merging with other 
OML envelopes or analytical work. The solution was breaking the problem of envelope production down into 
smaller parts (element level and sub-element level) and then concentrating on establishing quality products at each 
level. This enabled the production of an overall integrated vehicle level OML envelope that was suitable for use in 
the analysis areas and integration areas as described in this paper. In addition to the overall integrated vehicle outer 
mold line envelopes, there are several subtypes of envelope models pertaining to launch vehicle integration that 
supplement the overall element or integrated vehicle OML. One subtype is cavity regions, See Figure 1, which are 
internal volumes, not exposed directly to the air flow during initial stages of flight. The internal volume of an upper 
stage engine compartment, inter-stage, or inter-tank are examples of such cavity regions. These major cavity regions 
are exposed during staged flight and re-entry conditions. Component cavity regions, a smaller subset of cavity 
regions, are volumes adjacent to the ascent flow field, but which are otherwise removed from the flow stream. 
Examples of these are the volumes under the Reaction Control System (RCS) pods, Systems Tunnel, Booster 
Tumble Motors (BTM), etc. These volumes are closed off for the ascent aerodynamics analyses and require separate 
analysis. These types of envelopes are typically for venting analysis. 


Approximate Cavity Region 



Full Detail CAD 



Figure 1: Cavity Region 

Another subtype of envelope related to launch vehicle integration is an engine OML, See Figure 2, and is often 
the most cumbersome of all vehicle integration products because it is highly detailed, contains many complicated 
parts and geometries, and various integration/analysis functions have differing fidelity requirements for their 
analyses. 
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Figure 2: Engine OML 

Before we can talk about what constitutes an OML, its best to understand both how and when to implement the 
OML, not only for analysis, but also for integrated design control. The OML product may be produced by either of 
two methods; top-down, created based upon design intent; or bottom-up, by merging the lower level end item 
envelope models as produced by the subsystem design activities. Depending on the program structure and both the 
type and fidelity of analysis being performed, either method can be appropriate. The top-down method is typically 
used to drive the OML down from the vehicle integration function to the elements whereas the bottom-up method 
reports the resulting OML based upon lower level design activities. For example, using the top-down method, 
vehicle integration creates an OML, often a lower fidelity, and passes the overall integrated vehicle envelope to the 
elements as a design-to constraint. In contrast, the bottom-up approach takes the element provided OMLs and 
creates an integrated OML. A combination of both approaches (top-down and bottom-up) can be used. Early in the 
design cycle, when the element is allowed greater flexibility to alter their design, the top-down method is usually 
more appropriate. As the vehicle matures and the OML is baselined and controlled the bottom-up method will more 
accurately capture the integrated vehicle OML. As such, each stage element’s OML product must be submitted and 
integrated into the launch configuration before any downstream work can begin. 

Fidelity is a term used to describe the feature details included in an envelope and is a measure of how closely the 
envelope represents the actual surfaces of the as-designed models. Inclusion of envelope feature details are typically 
based upon specific uses (different types of analysis, component substitution for drawing development, etc), and the 
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fidelity of those features included in the envelope are targeted towards the needs of those use cases. The level of 
surface and feature fidelity must be matched to the downstream customer use case, as different customer use cases 
can have different fidelity requirements. 


REMOVE FASTENERS& SMALL HOLES 



FULL DETAIL MODEL 


OML MODEL 



Figure 3: Typical Simplification and Feature Inclusion 

For launch vehicle integration, it is often best to start with the highest fidelity envelope reasonable, and tailor (or 
simplify) the base OML to suit the other customer use cases. Typically, it is more efficient for the Vehicle 
Integration activity to perform any downstream simplifications required for analysis purposes since they have access 
to the highest fidelity envelopes and tools necessary to perform these simplifications. The top down approach, when 
used, occurs early in the design process and provides less fidelity at first; as you later transition to a controlled, 
higher fidelity OML, a transition to the bottom-up method is implemented. Feature details within a high fidelity 
envelope should closely represent the exterior surface of the assembly being enveloped. Surfaces for all components 
exposed to the exterior should be included in the envelope and match the original detail component models except 
for agreed upon simplifications. Typical simplifications at the high fidelity level are to remove fasteners and fill any 
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holes, cavities, or gaps between components that are smaller than an agreed upon threshold, See Figure 3. Threshold 
values used for space launch vehicle high fidelity envelopes are on the order of 0.25 inches to 1.0 inch. When a 
surface is included in an envelope it should retain as much of the basic feature size of the original component 
surface as possible. Cavity regions should be included with the OML product, but should be separable and distinct. 
Surface details to be included in the cavity region can be greatly simplified. Thresholds for feature sizes and 
approximations for details to include in these regions are on the order of 1.0 inch to 10 inches. Examples of typical 
simplification for cavity regions are the removal of machined webs, ribs, bosses, orthogrid patterns, small lines, etc.. 
Internals may be represented by a simulated volume. 

Like all OML models used for vehicle integration, the engine OML should be a water-tight, contiguous body 
representing the as-built configuration of the engine. It should contain all shields/TPS/etc., but small lines and ducts 
may be omitted. Generally speaking, the size threshold for inclusion of features into an engine OML is on the order 
of 2.0 inches. However, the engine OML should have sufficient fidelity to distinguish all major components and 
represent the overall size, location, and volume taken by the engine. While this model may still be too complicated 
for analysis purposes; greater simplification may be performed as required to support the analyses Internal Engine 
and solid rocket motor nozzle surfaces are included in the engine OML up to the throat of the nozzle; additional 
detail forward the nozzle throat is usually not required. See Figure 4. 




FULL DETAIL MODEL SIMPLIFIED NOZZLE INTERNALS 

Figure 4: Nozzle Simplification 

Envelope products are the basis for many aspects of vehicle integration (both physical and analytical)., The 
OML model is used in aerodynamics analysis, vehicle assembly drawings, envelope drawings, thermal heating 
analyses, venting analyses, pad and launch accessory design, logistics flow diagrams, stacking simulations, Interface 
Control Documents (ICDs), layouts, and various project level documents where views of the vehicle are required. 
Preliminary aerodynamic analyses occur early in the design cycle, and must be completed before most other 
disciplines can begin. OML models are used as the basis for most aerodynamics related analyses such as 
Computational Fluid Dynamics (CFD), Experimental (wind tunnel testing), Aero-acoustics, Aero-elasticity, Aero- 
thermal, Lift-off Acoustics, Re-entry and Break-up Analyses, and Range Safety/Debris Field Analyses. 

Depending upon the fidelity of the envelope model produced, the resulting OML product may be used as a 
simplified substitute for the end item assembly. This enhances productivity and allows for data encapsulation to 
remove extraneous detail and company proprietary information. Simplification of the assembly definition also 
improves productivity for activities such as higher level integrations and design documentation. 

In addition to surface geometries, additional features should be included in the single part OML envelope to aid 
in the definition of the elements and integrated vehicle. Every OML model (both element and vehicle) should be 
constructed in the element coordinate frame and that coordinate frame should be included in the model for assembly 
and integration purposes. Separable assemblies, or assemblies that are jettisoned during flight but are otherwise part 
of the continuous OML solid, should include a datum feature or surface denoting the parting line of separation. 
Operational Interfaces, such as access doors, umbilical panels, service panels, etc., should be identified, as practical, 
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in order to assist Ground System design efforts. In these cases, the inclusion of character surfaces/lines representing 
doors, etc. is warranted. Features required for identifying operational or interface characteristics are typically 
included. These include but are not limited to: Separation Planes; Keep Out/In Zones; Access Door Openings; etc. 

As with any CAD model for any design purposes, there can be quality concerns with the model itself. When 
merging element OMLs or sub-element OMLs together the single biggest issue is surface or part accuracy of the 
original models; therefore, it’s ideal for the models/surfaces to have the same accuracy. When constructing 
envelopes, matching surface or part accuracies are needed and upstream use of the envelope should be considered 
when determining this accuracy. Typically, the larger the envelope constructed (or as smaller features are integrated 
into a larger envelope), the greater the need for increased accuracy. Otherwise, small features considered necessary 
might not be accurately represented. Even though the element OML provided to vehicle integration is a standalone 
single part file, other CAD quality issues can affect its creation. Items such as circular references, geometry issues 
(such as disjoined edges and sliver surfaces) can hamper the construction of the element OML. Most design 
organizations, commercial and government, have CAD standards that address quality, but often these standards are 
not applied until the design parts are released. MSFC has developed a standard for CAD modeling, MSFC-STD- 
3528 3 , to address the issues necessary to create quality parts and assemblies. Vehicle analysis and integration 
activities occur at all stages of the design cycle, and most are complete prior to element part release. Therefore, it is 
important that some aspects of the quality controls of the parts/assemblies in question be instituted earlier in the 
design cycle to aid in downstream vehicle integration activities. 

These envelopes may act as a substitute for complex detailed models/assemblies within higher level assemblies 
and when shared with outside design groups, such as an integration activity. This can greatly simplify the processing 
time for integrating and utilizing the dataset at multiple levels. They also reduce the overhead required by reducing 
the number of files that have to be translated, transferred, and maintained. An added benefit of having the element 
responsible for creation and ownership of their element OML is it gives them early insight into model quality and 
how potential changes to the OML affect their own element integration effort, often catching potential problems 
earlier in the design process. An envelope also accommodates the need for sharing of critical design information 
without exposing internal details which are considered proprietary. 

III. Interfaces 

Another approach for improvement to vehicle integration activities deals with mechanical interfaces, specifically 
those which occur within a design when two mating elements are being physically brought together. A mechanical 
interface will generally be characterized by a physical attachment between the two mating elements however; an 
interface may also include hardware components that must fit into one another, such as a payload within a fairing or 
an engine within an enclosure. The general requirement to be achieved by an interface is to mate the opposing 
elements together and to maintain clearance between the two mating elements. Therefore, the areas of interest when 
working the integration of a mechanical interface are any areas where physical attachment or contact occurs between 
the two mating sides and the static and dynamic clearance between the interface and any surrounding element 
envelopes. In either case, the critical aspects of the interface must be captured and controlled to ensure the 
interfacing elements meet the requirements of the design. Lessons learned when integrating the vehicle level 
interfaces within the Ares I launch vehicle design were used to develop this approach; in particular, methods found 
most useful in dealing with the overwhelmingly large CAD datasets representing the design of launch vehicles are 
presented. 

The elements of a launch vehicle, from a vehicle integration point of view, are the vehicle stages including in- 
flight separation and ground support systems. The comprehensive design for each of these elements can each contain 
thousands of separate CAD models (parts and assemblies) of which only a fraction of these are necessary in 
capturing and controlling the critical aspects of a vehicle level interface. Our initial efforts to define an interface 
within our CAD and PDM tools involved bringing these massive assemblies into a single PDM system and 
assembling them together into an overall vehicle assembly. While this method included all detail needed to evaluate 
and document the interface, performance of data exchanges and downstream processes using this massive dataset 
involved a significant amount of unnecessary, and time consuming, effort. This extra work created a significant 
impact on manpower required, and on the overall schedule of activities required to evaluate and control the 
interface. 

The method that we developed to improve the management of the CAD portion of the interface was to focus on 
only the subset of models necessary in order to capture the critical aspects of the interface and thereby remove all 
extraneous design detail and references. This was accomplished by the use of discrete packages of data specifically 
targeted to each vehicle level interface. These design product packages, which we refer to as Interface Detail 
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Products (IDPs), include an extraction of the CAD models directly related to each side of the interface and are 
produced by their respective element level design activities, See Figure 5. The IDPs also contain an OML envelope 
of the element and any additional data as needed to accompany the CAD portion of the interface definition. This 
product package fully supports the needs of the vehicle integration activity for evaluation, reconciliation, and 
documentation of the critical aspects of the Ares 1 vehicle interfaces. In order to better benefit from using this 
method, the documentation of an interface should be as generic as possible. To the extent allowable, the IDP 
package should not contain “background detail” that is subject to change as the design matures. Where practical, all 
parties (IDP submitters, the vehicle integration activity, and interface documentation activity) should endeavor to 
construct and arrange details of the interface documentation so that only the information required to capture the 
critical aspects of the interface is shown and superfluous detail is omitted. Packaging of this data eliminated the need 
for large scale exchange and management of CAD data in order to integrate the vehicle level interface details. 



Figure 5: Example IDP CAD portion, sides to be mated 


The CAD portion of the IDP should contain only the fdes necessary for the interface, therefore it becomes much 
easier to exchange than full element datasets. One caveat when extracting the CAD portion of the IDP is that this 
data must be managed in a way that removes all external dependencies. This can be done by various methods 
depending upon the CAD tool used, however a typical process is to utilize an intermediate neutral format such as 
STEP to process the package in order to break dependencies. Our method, used for ARES I, utilized a two part 
process. First, a neutral format translation was performed to produce the disassociated assembly structure, removing 
unneeded parts and subassemblies. Secondly, the parts related to the interface were reintegrated into the assembly 
using their native CAD format. Reuse of the native CAD parts required the removal of all external dependencies 
within those parts. 

In addition to the CAD portion, the IDP should contain drawings and layouts specifying the dimensions, 
tolerances, form control, salient notes, schematics, vender parts, etc. for that particular interface. Prior to completion 
of the piece part drawings (which typically specify this type of information) as much of this information should be 
communicated to the integration authority and interface documentation activity as possible. Where detailed 
dimensional data, notes, and specifications are un-available or un-resolved, a “place-holder” for that information 
should be given. Our process for creation of an IDP package is shown in Figure 6. 
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Our process of interface integration is to require each design participant (or “side” of an interface) to 
simultaneously submit to the integration activity an IDP. The integration activity and documentation activity will 
then review the submissions for inclusion of all required data items. Next, the IDP CAD models are mated with the 
opposing side and a manual inspection is completed to ensure that the mating assemblies and critical features align. 
The CAD models are located using their respective element coordinate frames which allow the integration activity 
to assemble the mating sides of the interface based upon element locations in context of the vehicle. Each side of the 
interface is then evaluated for completeness and agreement of all critical interface aspects related to the design 
constraints and intent of the interface. If required, a resolution of any discrepancies is performed. The critical aspects 
of the interface are then captured into a separate model maintained by the integration activity and used to produce 
the controlling documentation for the interface. This allows for updates of an IDP without unwanted changes 
occurring to the controlled interface definition. Where updates to the IDPs occur, the controlled aspects of the 
interface may be utilized on an as needed basis to reconcile differences between the controlled interface definition 
and the submitted change. 

Views and figures to support the interface documentation are developed from the assembly of the two mating 
IDPs. The OML envelopes are shown as reference entities that are used to visually evaluate whether sufficient static 
and dynamic clearance exists. It is a recommended practice to establish zone boundaries to define and maintain the 
clearances necessary to support function of the interface. These zones are captured along with other critical aspects 
of the interface into the model maintained by the interface activity. Updates to OML envelopes are therefore not a 
cause for a change in the interface definition unless the controlled zone boundaries are violated which simplifies 
maintenance of the interface. The critical aspects of the interface are documented in views and figures (often within 
interface drawings) and are controlled by the interface authority. 

The extraction of subsets of the comprehensive CAD dataset is best performed by the element design activity as 
they are the most knowledgeable about their side of the interface and able to more easily identify the parts and 
assemblies that are required to be coordinated with the mating side of the interface. Sufficient standard CAD 
processes must be established in order to allow successful integration between elements that may be independently 
developed and designed. NASA has been working on minimum requirements for the interoperability of CAD 
datasets that incorporates many lessons learned from the ARES I program. NASA technical standard “NASA 
Computer-Aided Design Interoperability”, NASA-STD-0007 4 , provides examples of the type of guidance for 
accuracy control, file naming, and external references among other things that will directly relate to the ability to 
perform processes such as the one described herein for interface management. Additional guidance beyond that in 
NASA-STD-0007 is recommended to disallow the use of assembly features, such as assembly cuts, holes, etc., for 
CAD items included in an IDP as it is difficult to capture assembly part variations into the extracted CAD assembly 
structure. 

Since the design packages only represent a small percentage of the comprehensive CAD dataset, these packages 
can be reviewed and reconciled faster and more efficiently by the design participants (submitters) and the integration 
activity. Another virtue of the packages is that they are an “extraction” of the comprehensive CAD dataset and stand 
alone from the associations and dependencies that exist within the native design environment; the integration 
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activity can modify these CAD files in order to establish interface control, resolve differences, render generic, or 
publish the graphical views in an interface document or drawing. 

IV. Conclusion 

Many common practices used for the management and development of CAD data are not scalable to the 
massively large CAD assemblies needed in the design of Space Launch Vehicles. The out of the box capabilities for 
creating envelopes and subsets of CAD data, common within modern CAD systems, doesn’t meet the requirements 
of working with the massive design assemblies needed for the Ares 1 Project. Only when more robust creation 
methods, such as those described in this paper, are applied judiciously, do these principals become relevant to large 
design projects. The methods for the creation and use of OML envelopes along with the extraction and packaging of 
subsets of CAD data, streamlined design integration within the ARES I Space Launch Vehicle design effort. Many 
of the downstream products necessary for vehicle integration, such as analysis products, benefit from the successful 
implementation of these methods. 

Specifically, the use of envelopes to represent an assembly of items and reduce the assembly into a single usable, 
easily accessed, exchanged, and updatable model has proven invaluable in our design efforts relating to vehicle 
integration. The overhead required when using, managing, and exchanging the full comprehensive data between our 
various organizations and disciplines overwhelmed the capabilities of existing processes within NASA and the need 
for high quality envelopes quickly became apparent. Out of the box vendor methods couldn’t scale up to the size and 
complexity of such large scale projects. The lack of usability of the out of the box envelopes due to non-contiguous 
surfaces, missing details and unwanted dependencies rendered this approach ineffective. Also, the failure of the out 
of the box CAD envelope production methods to consistently produce an envelope for large scale assemblies lead to 
the further need for a robust envelope creation method for large scale design. The envelope concept described in our 
approach is more targeted to large design assemblies, so that lower level envelopes can be merged into larger, 
overall envelopes. While the learning curve to create these high fidelity OMLs was not insignificant, it was found 
that usage of these OML envelope models reduced design resource requirements (memory and computation time), 
and the associated processing times for viewing and working with large assemblies, by a factor of 10 to 100. 
Additionally, significant time savings was achieved when performing analysis cycles by giving the analyst an OML 
rather than requiring them to build their analytical models from scratch. 

Another significant improvement is the concept of extracted subsets of data and packaging the data together into 
design product packages which not only includes the CAD portion of the design definition but also all ancillary 
product necessary to support the targeted activity that is under consideration. Specifically for interfaces, the 1DP 
package when used during the integration of vehicle elements yielded similar savings in overall time and effort. This 
focus on a specific product allowed for those outside the integration activity to better understand the needs for 
integration, thereby increasing quality of the package contents and providing the ability to follow and improve the 
package contents as the design matures. A relative comparison, using the full comprehensive CAD data versus the 
use of IDP packages, was performed during the initial attempt to document interfaces. The attempt using full 
comprehensive CAD data took months to accomplish and did not produce the desired result. The alternative method 
described herein was applied, successfully producing the kinds of insight into the interface design needed along with 
assisting in documentation of the interfaces. 

This method of using envelopes and packages of targeted design information, as described for interface 
management, supports most of the integration insight and products produced for our vehicle design integration 
activities. When additional design details are required, light weight visualizations are utilized to answer questions 
about the accuracy of the simplified products and to ensure that no pertinent details were omitted from the reduced 
data packages. The approach of using envelopes and design product packages have also been found to be useful in 
other areas of vehicle integration such as vehicle stack alignments and guidance, navigation, and control (GN&C) 
component alignments. 

Therefore, the use of Envelopes and Design Product Packages when utilized within a collaborative design effort 
increases design productivity, improves design cycle time and reduces superfluous exchange and management of 
CAD data. 
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